3장. 채점이 제일 어렵다 (평가)
출처: 『AI 엔지니어링』(Chip Huyen 지음) | 원서: AI Engineering (O'Reilly) — 본 입문판은 PDF 원문에서 직접 풀어 썼다.
코드는 분위기만 — Python·점수·수식 같은 말은 몰라도 됩니다. '비유'와 '위험'만 봐도 충분해요.
AI를 많이 쓸수록 사고도 늘었다.
챗봇 말에 휘둘려 극단적 선택을 한 사람, AI가 지어낸 가짜 판례를 법정에 낸 변호사, 챗봇이 손님에게 잘못 안내해 회사가 배상한 항공사.
이런 사고는 다 같은 한 가지를 못 해서 생긴다.
AI가 내놓은 답이 좋은지 나쁜지 제대로 채점하지 못한 것.
그래서 많은 팀이 깨닫는다.
AI 앱을 만들 때 제일 어려운 일은 만드는 게 아니라 채점(평가) 이라는 걸.
어떤 팀은 평가 방법을 짜는 데 가장 많은 시간을 쓴다.
0. 이 장의 새 단어 (3개만)
0장 용어집에 없는, 이 장에서 처음 나오는 말 3개다.
나머지 어려운 말(평가·벤치마크·임베딩·환각 등)은 전부 0장에 있다. 막히면 0장으로.
퍼플렉시티(perplexity, PPL)
한 문장 뜻 — 모델이 다음 단어를 맞힐 때 얼마나 헷갈려하는지를 나타내는 숫자. 낮을수록 덜 헷갈린다.
일상비유 — 객관식 보기 개수. 보기가 2개면 덜 헷갈리고(퍼플렉시티 낮음), 보기가 50개면 많이 헷갈린다(퍼플렉시티 높음).
한 줄 예 —
# 아래 예제는 핵심 흐름만 짧게 보여 줍니다.
# 퍼플렉시티 4 = "보기 4개 중 하나 고르는 정도로 헷갈린다"
ppl = 4 # 낮을수록 모델이 다음 단어를 잘 맞힌다
AI 평가자(LLM-as-judge)
한 문장 뜻 — 사람 대신 AI한테 "이 답 잘했어?"라고 물어, AI가 채점하게 하는 방식.
일상비유 — AI 조교에게 채점 맡기기. 선생님(사람)이 일일이 채점하면 느리고 비싸니까, 똑똑한 조교(AI)한테 채점을 시킨다.
한 줄 예 —
# 답을 또 다른 AI에게 "1~5점으로 매겨줘"라고 시킴
# 검색·답변 품질을 점수나 기준으로 비교합니다.
score = judge_ai.ask("이 답 얼마나 좋아? 1~5점", answer)
비교 평가(comparative evaluation)
한 문장 뜻 — 모델 하나하나에 점수를 매기는 대신, 둘을 나란히 놓고 "어느 쪽이 더 나아?"만 물어 순위를 매기는 방식.
일상비유 — 댄스 배틀. 댄서마다 점수표를 매기기는 어렵지만, 둘을 나란히 춤추게 하고 "누가 더 잘해?" 고르는 건 쉽다.
한 줄 예 —
# 아래 예제는 핵심 흐름만 짧게 보여 줍니다.
# 두 답 중 더 나은 쪽만 고름 (점수 X)
winner = vote(answer_A, answer_B) # → "A" 또는 "B"
채점이 제일 어렵다 — 왜?
옛날 AI는 채점이 쉬웠다.
감정 분석 모델은 답이 "긍정/부정" 둘 중 하나다. 정답이 "긍정"인데 "부정"이라 하면 그냥 틀린 거다. 끝.
그런데 파운데이션 모델은 다르다.
# 옛날 모델 — 답이 정해진 보기 중 하나
answer = "긍정" # 정답과 다르면 = 틀림. 채점 끝.
# 파운데이션 모델 — 답이 무한히 많음
# `answer`에 중간 결과를 담아 다음 줄에서 재사용합니다.
answer = model.ask("프랑스어 'Comment ça va?' 영어로 번역해줘")
# "How are you?" "How is everything?" "How is it going?" ... 다 정답
정답이 하나가 아니라 수십 개다.
"이게 정답"이라고 목록을 다 만드는 건 불가능하다.
그래서 채점이 어렵다. 이 한 가지가 이 장 전체를 관통한다.
이 장에서 딱 4가지만 (TL;DR)
- 파운데이션 모델은 채점이 어렵다. 모델이 똑똑할수록·답이 열려 있을수록 더 어렵다. 그래서 눈대중("괜찮네") 대신 체계적 채점이 필요하다.
- 퍼플렉시티 — 모델이 다음 단어를 얼마나 잘 맞히는지 나타내는 숫자. 모델 자체 성능을 가늠하는 내부 점수다. 낮을수록 좋다.
- 정답이 있을 때의 채점 — 코드는 돌려보면 된다(기능적 정확성). 번역·요약은 모범답안과 비교한다(어휘적·의미적 유사도).
- 정답이 열려 있을 때의 채점 — AI에게 채점을 시키거나(AI 평가자), 둘을 나란히 비교한다(비교 평가). 빠르지만 편향이 있다.
각 꼭지를 차례로 본다.
1. 퍼플렉시티 — 모델이 얼마나 헷갈려하는가
망가지는 장면
"두 모델 중 뭐가 더 좋은지 알고 싶은데, 둘 다 답은 그럴듯하다. 뭘로 비교하지?"
답을 보기 전에, 모델이 다음 단어를 얼마나 잘 맞히는지부터 재 보면 힌트가 된다.
다음 단어를 잘 맞히는 모델은 다른 일도 잘하는 경향이 있다.
비유 먼저
객관식 시험의 보기 개수를 떠올려 보자.
"나는 마시는 걸 좋아한다 (I like drinking ___)" 다음에 올 단어를 맞힌다고 하자.
모델이 "차(tea)"를 콕 집으면 — 헷갈림이 적다. 퍼플렉시티 낮음.
"숯·차·돌·물·기름…" 수십 개를 똑같이 헷갈려하면 — 퍼플렉시티 높음.
퍼플렉시티가 4라는 건 "보기 4개 중에서 찍는 정도로 헷갈린다"는 뜻이다.
3열표
| 비유 | 코드 | 위험 |
|---|---|---|
| 보기 2개 = 덜 헷갈림 | ppl = 2 # 낮음 = 좋음 |
낮다고 무조건 좋은 건 아님(아래 위험 참조) |
| 보기 50개 = 많이 헷갈림 | ppl = 50 # 높음 = 나쁨 |
어휘가 많으면 자연히 높아짐 — 모델 탓 아닐 수 있음 |
| 답을 다 외워 버림 | ppl = 1.01 # 너무 낮음 |
시험지를 미리 본 것일 수 있음(데이터 오염) |
한 문장 정의
퍼플렉시티는 모델이 다음 단어를 예측할 때의 헷갈림 크기이며, 낮을수록 모델이 글을 잘 맞힌다는 뜻이다.
예시 폭격
예시 1 (완성예 — 큰 모델이 더 잘 맞힘).
오픈AI의 GPT-2 보고서를 보자.
# 아래 예제는 핵심 흐름만 짧게 보여 줍니다.
# 모델이 클수록 퍼플렉시티가 낮다 = 다음 단어를 더 잘 맞힌다
small_model = 35.13 # 작은 모델 (1억 1700만 손잡이)
big_model = 8.63 # 큰 모델 (15억 4200만 손잡이) → 훨씬 낮음 = 더 좋음
큰 모델이 일관되게 더 낮은 퍼플렉시티를 보였다.
예시 2 (부분완성 — 빈칸 채우기).
다음 두 글 중, 모델이 덜 헷갈려할(퍼플렉시티가 낮을) 쪽은?
# 아래 예제는 핵심 흐름만 짧게 보여 줍니다.
글_A = "<head> ... </head>" # HTML 코드 (규칙적)
글_B = "오늘 점심 뭐 먹지 고민되네" # 일상 잡담
# 답: 글___ 가 퍼플렉시티 낮음
답은 글_A다.
HTML은 <head>를 보면 곧 </head>가 온다고 척 안다. 규칙적이라 덜 헷갈린다.
예시 3 (독립적용 — 직접 판단).
같은 모델로 다음 둘을 읽힌다. 퍼플렉시티가 더 높은 쪽은?
# 아래 예제는 핵심 흐름만 짧게 보여 줍니다.
글_C = "엄마가 방에 들어왔다" # 평범
글_D = "우리 강아지는 여가 시간에 양자역학을 가르친다" # 황당
답은 글_D다.
말이 안 되는 문장이라 모델이 "이 다음에 뭐가 오지?"를 전혀 못 맞힌다. 그래서 퍼플렉시티가 치솟는다.
이 성질을 거꾸로 쓰면 이상한 글 찾아내기가 된다.
미니 시나리오 — 퍼플렉시티 활용 4가지
"퍼플렉시티 숫자 하나로 뭘 할 수 있나요?"
# 아래 예제는 핵심 흐름만 짧게 보여 줍니다.
# ① 모델 성능 가늠 — 다음 단어도 못 맞히면 딴 일도 잘 못함
# ② 시험지 유출 잡기 — 벤치마크 글에 퍼플렉시티가 비정상으로 낮으면, 그 글로 이미 공부한 것(데이터 오염)
# ③ 중복 자료 거르기 — 새 글의 퍼플렉시티가 낮으면 비슷한 게 이미 있다는 뜻 → 안 넣음
# ④ 이상한 글 탐지 — 퍼플렉시티가 치솟으면 의미 없는/특이한 글
단순 규칙
모델끼리 비교할 땐 퍼플렉시티가 낮은 쪽이 기본적으로 더 낫다.
한 걸음 더 ▸ (지금 몰라도 됨)
퍼플렉시티가 낮다고 항상 좋은 건 아니다.
① 사람 취향을 입힌 모델(SFT·RLHF로 다듬은 모델) 은 오히려 퍼플렉시티가 올라간다. 다음 단어 맞히기보다 "사람이 좋아할 답"을 내도록 바뀌었기 때문이다. 그래서 이런 모델엔 퍼플렉시티 채점이 안 맞는다.
② 시험지를 미리 본 모델 도 퍼플렉시티가 비정상으로 낮다(데이터 오염).
SFT·RLHF가 뭔지는 0장 범위 밖이라 몰라도 된다. "다듬은 모델엔 이 점수가 안 맞는다"만 기억하면 충분하다.
부록 박스 — 숫자 단위 (참고용, 건너뛰어도 됨)
퍼플렉시티는 교차 엔트로피라는 값에 지수를 씌운 것이다(
퍼플렉시티 = 2^교차엔트로피). 교차 엔트로피는 "모델이 데이터를 얼마나 예측하기 어려워하는가"를 비트 단위로 잰 값이다.모델마다 글을 쪼개는 방식(토큰)이 달라 그냥은 비교가 안 된다. 그래서 BPC(문자당 비트), BPB(바이트당 비트) 로 단위를 맞춰 비교한다. 예: 교차 엔트로피 6비트, 토큰 1개가 2글자면 BPC = 6/2 = 3.
이 수식들은 분위기만 알면 된다. 결론은 하나 — "모델이 다음 글자를 얼마나 잘 맞히나"를 재는 값이다.
2. 정답이 있을 때 — 돌려보고 채점하기 (기능적 정확성)
망가지는 장면
"AI가 짠 코드가 그럴듯해 보여서 넘겼는데, 막상 실행하니 엉뚱한 답이 나왔다."
코드는 눈으로 보지 말고 돌려봐야 한다.
돌려서 맞는 답이 나오면 맞는 코드, 아니면 틀린 코드. 깔끔하다.
비유 먼저
리트코드·해커랭크 같은 코딩 사이트를 떠올려 보자.
제출하면 사이트가 여러 입력으로 코드를 돌려본다. 다 통과하면 정답 처리.
이렇게 "의도한 대로 진짜 작동하는가"로 채점하는 게 기능적 정확성이다.
3열표
| 비유 | 코드 | 위험 |
|---|---|---|
| 코드 돌려서 맞는지 확인 | gcd(15, 20) == 5 # 맞으면 통과 |
돌려볼 수 없는 작업(에세이 등)엔 못 씀 |
| 코딩 사이트 자동 채점 | assert candidate([1.0,2.0], 0.3) == True |
테스트 케이스가 부실하면 헛통과 |
| 게임 봇 점수로 채점 | score = play_tetris(bot) # 점수 높을수록 좋음 |
점수로 잴 수 있는 작업만 가능 |
한 문장 정의
기능적 정확성은 시스템이 의도한 기능을 실제로 해내는지 직접 돌려서 채점하는 방식이며, 코드·게임처럼 결과를 측정할 수 있는 작업에 쓴다.
예시 폭격
예시 1 (완성예 — 코드 채점).
# 아래 예제는 핵심 흐름만 짧게 보여 줍니다.
# 모델에게 최대공약수 함수를 짜 달라고 함
def gcd(num1, num2): ... # 모델이 생성한 코드
# 돌려서 확인 — 15와 20의 최대공약수는 5
gcd(15, 20) # 5가 나오면 정답, 아니면 오답
예시 2 (부분완성 — pass@k 계산).
문제 10개가 있다. 모델이 문제마다 코드를 3개씩 만든다(k=3). 그중 하나라도 모든 테스트를 통과하면 그 문제는 해결.
# `문제_수`에 중간 결과를 담아 다음 줄에서 재사용합니다.
문제_수 = 10
해결한_문제 = 5 # 3개 중 하나라도 통과한 문제가 5개
pass_at_3 = 해결한_문제 / 문제_수 # = ___%
답은 50%다 (5/10).
샘플을 많이 만들수록 맞힐 확률이 오르니, pass@1 < pass@3 < pass@10.
예시 3 (독립적용 — 어디에 쓸까).
다음 중 기능적 정확성으로 채점할 수 있는 작업은?
# 아래 예제는 핵심 흐름만 짧게 보여 줍니다.
작업_A = "에너지를 가장 적게 쓰도록 일정 짜기" # 절약량을 잴 수 있음
작업_B = "감동적인 시 쓰기" # 감동은 숫자로 못 잼
답은 작업_A다.
절약한 에너지양이라는 측정 가능한 목표가 있다. 작업_B는 다음 방법으로 넘어간다.
단순 규칙
돌려보거나 점수로 잴 수 있는 작업이면 기능적 정확성이 가장 확실하다.
3. 정답이 있을 때 — 모범답안과 비교하기 (유사도)
망가지는 장면
"번역은 돌려볼 수가 없잖아. 그럼 번역이 잘됐는지 어떻게 채점하지?"
이럴 땐 모범답안(참조 데이터) 을 옆에 두고 비교한다.
생성된 답이 모범답안과 비슷할수록 좋은 답으로 친다.
비유 먼저
받아쓰기 채점을 떠올려 보자.
모범답안과 글자 하나하나 맞춰 보는 게 어휘적 유사도(글자 겹침).
뜻이 같으면 글자가 달라도 맞다고 쳐 주는 게 의미적 유사도(뜻 겹침).
3열표
| 비유 | 코드 | 위험 |
|---|---|---|
| 정확히 똑같아야 정답(정확한 일치) | answer == "5" |
표현이 조금만 달라도 오답 처리 |
| 글자 겹친 비율로 채점(어휘적) | "My cats eat the mice" → 4/5 겹침 |
뜻 같아도 글자 다르면 낮은 점수 |
| 뜻 가까운 정도로 채점(의미적) | cos(임베딩_A, 임베딩_B) |
임베딩 품질 나쁘면 채점도 엉터리 |
한 문장 정의
유사도 채점은 생성된 답을 모범답안과 비교하는 방식이며, 글자 겹침을 보는 어휘적 유사도와 뜻 겹침을 보는 의미적 유사도가 있다.
예시 폭격
예시 1 (완성예 — 정확한 일치의 함정).
"안네 프랑크는 언제 태어났나요?" 정답은 1929년 6월 12일.
모델_답 = "1929년 9월 12일" # 날짜가 틀림!
# `정답_연도`에 중간 결과를 담아 다음 줄에서 재사용합니다.
정답_연도 = "1929"
# "정답 연도가 들어 있으면 정답" 규칙을 쓰면…
정답_연도 in 모델_답 # True → 정답 처리. 하지만 사실은 틀린 답!
정확한 일치는 "2+3은?" 같은 짧고 또렷한 답에만 안전하다.
예시 2 (부분완성 — 어휘적 유사도 계산).
# 아래 예제는 핵심 흐름만 짧게 보여 줍니다.
참조 = "My cats scare the mice" # 5단어
응답A = "My cats eat the mice" # 겹친 단어: My, cats, the, mice = 4개
응답B = "Cats and mice fight all the time" # 겹친 단어: cats, mice, the = 3개
유사도_A = 4 / 5 # = ___%
유사도_B = 3 / 5 # = 60%
유사도_A는 80%다. A가 참조와 더 비슷하다고 본다.
예시 3 (독립적용 — 어휘 vs 의미).
다음 두 문장은 글자가 거의 안 겹친다. 어휘적 유사도로는 낮은 점수다. 그런데 뜻은?
# `문장_X`에 중간 결과를 담아 다음 줄에서 재사용합니다.
문장_X = "What's up?"
# `문장_Y`에 중간 결과를 담아 다음 줄에서 재사용합니다.
문장_Y = "How are you?"
# 어휘적 유사도: 낮음 (겹치는 단어 거의 없음)
# 의미적 유사도: ____ (뜻은 거의 같음)
의미적 유사도는 높다.
뜻이 같으니까. 이래서 번역·요약 같은 열린 작업엔 의미적 유사도가 더 잘 맞는다.
미니 시나리오 — 어휘적 유사도가 좋은 답을 떨어뜨린 사고
"우리 모델이 사진 설명을 정확히 했는데 점수가 0.4밖에 안 나와요?"
Adept라는 회사의 Fuyu 모델이 야경 사진을 "빅벤과 국회의사당의 야경"이라고 정확히 캡션했다.
그런데 모범답안 목록에 '빅벤'이라는 단어가 없었다.
글자가 안 겹치니 어휘적 유사도(CIDEr) 점수가 0.4로 깎였다 — 답은 맞는데도.
# 아래 예제는 핵심 흐름만 짧게 보여 줍니다.
# 모범답안에 그 단어가 없으면, 맞는 답도 점수가 깎인다
모범답안 = ["시계탑이 있는 야경", "차들이 지나가는 밤거리"] # '빅벤' 없음
모델_답 = "빅벤과 국회의사당의 야경" # 정확하지만 글자가 안 겹침 → 0.4점
단순 규칙
짧고 또렷한 답이면 정확한 일치, 열린 답이면 의미적 유사도가 안전판이다.
한 걸음 더 ▸ (지금 몰라도 됨)
어휘적 유사도의 대표 점수는 BLEU·ROUGE·METEOR·TER·CIDEr다. 글자·단어 겹침을 재는 방식이 조금씩 다를 뿐, 다 "얼마나 겹치나"를 본다.
의미적 유사도는 글을 임베딩(0장 참조 — 뜻을 숫자 목록으로 바꾼 것)으로 바꾼 뒤, 두 임베딩이 얼마나 가까운지(코사인 유사도)를 잰다. 대표 점수는 BERTScore·MoverScore.
점수 이름은 외울 필요 없다. "글자 겹침이냐, 뜻 겹침이냐" 둘만 구분하면 된다.
부록 박스 — 임베딩 한 조각 (참고용)
의미적 유사도의 바탕이 임베딩이다. 임베딩은 0장에서 봤듯 "뜻을 숫자 목록(벡터)으로 바꿔, 뜻이 비슷하면 숫자도 가깝게" 만든 것이다.
실제 임베딩은 숫자 100~10,000개짜리 목록이다. 좋은 임베딩이면 'the cat sits on a mat'이 'AI research is super fun'보다 'the dog plays on the grass'에 더 가까워야 한다.
글뿐 아니라 이미지도 임베딩으로 바꿀 수 있다. 글과 이미지를 같은 공간에 놓으면, "어부"라는 글로 낚시 사진을 찾는 것도 된다(멀티모달 — 0장 참조). 임베딩 품질을 종합 채점하는 표준 시험지가 MTEB다.
4. 정답이 열려 있을 때 — AI에게 채점 시키기 (AI 평가자)
망가지는 장면
"답이 무한히 많은 작업은 모범답안을 못 만든다. 사람이 일일이 채점하자니 느리고 비싸다. 그럼 어쩌지?"
답: AI한테 채점을 맡긴다.
답을 또 다른 AI에게 보여 주고 "이거 얼마나 좋아?"라고 물으면, AI가 점수를 매긴다.
비유 먼저
AI 조교에게 채점을 맡기는 셈이다.
선생님(사람)이 직접 채점하면 정확하지만 느리고 비싸다.
똑똑한 조교(AI)는 빠르고 싸다. 게다가 모범답안 없이도 채점할 수 있다.
2023년 한 보고서에 따르면 어떤 플랫폼 평가의 58%가 AI 평가자로 이뤄졌다.
3열표
| 비유 | 코드 | 위험 |
|---|---|---|
| 조교가 1~5점 매김 | judge.ask("1~5점", 답) |
같은 답에도 매번 점수가 흔들림 |
| 조교가 모범답안과 비교 | judge.ask("참조랑 같아? True/False", 답) |
채점 기준이 도구마다 제각각 |
| 조교가 둘 중 고름 | judge.ask("A와 B 중 뭐가 나아?") |
첫 번째·긴 답을 편애함 |
한 문장 정의
AI 평가자는 AI에게 다른 AI의 답을 채점하게 하는 방식이며, 빠르고 모범답안이 필요 없지만 편향과 흔들림이 있다.
예시 폭격
예시 1 (완성예 — 세 가지 채점 방식).
# 방식 1: 점수 매기기 (1~5점)
# 준비한 함수나 객체를 호출해 예제의 핵심 동작을 실행합니다.
judge.ask("이 응답이 질의에 얼마나 좋아? 1점(나쁨)~5점(좋음)", 질의, 응답)
# 방식 2: 모범답안과 같은지 (True/False)
# 준비한 함수나 객체를 호출해 예제의 핵심 동작을 실행합니다.
judge.ask("이 응답이 참조 응답과 같아? True/False", 참조, 응답)
# 방식 3: 둘 중 고르기 (A/B)
# 준비한 함수나 객체를 호출해 예제의 핵심 동작을 실행합니다.
judge.ask("두 응답 중 어느 게 더 나아? A/B", 응답1, 응답2)
예시 2 (부분완성 — 좋은 채점 지시 만들기).
AI 평가자에게 잘 채점시키려면 지시에 3가지가 들어가야 한다.
# `프롬프트`에 중간 결과를 담아 다음 줄에서 재사용합니다.
프롬프트 = """
1. 할 일: 응답이 질의와 관련 있는지 평가해라
2. 기준: 응답이 질의를 충분히 다루는지 봐라 (자세할수록 좋음)
3. 점수 체계: ____ # 분류(좋음/나쁨)? 1~5점? 0~1 사이?
"""
빈칸엔 분류 또는 1~5점이 들어가야 좋다.
AI는 0~1 사이 같은 연속 점수보다 분류(좋음/나쁨)를 더 일관되게 매긴다.
예시 3 (독립적용 — 자유로운 채점).
AI 평가자는 어떤 기준으로든 물어볼 수 있다. 다음도 가능할까?
# 아래 예제는 핵심 흐름만 짧게 보여 줍니다.
judge.ask("이 대답이 간달프가 할 법한 말이야?", 챗봇_응답) # 역할 연기 채점
judge.ask("이 홍보 사진 속 제품이 얼마나 신뢰감 있어? 1~5점", 이미지) # 이미지 채점
둘 다 가능하다.
사람한테 아무 의견이나 물어볼 수 있듯, AI 평가자에게도 어떤 기준이든 시킬 수 있다.
미니 시나리오 — AI 평가자는 "모델 + 지시" 한 묶음이다
"평가자 점수가 지난달이랑 다른데, 우리 앱이 좋아진 건가요?"
함정이다.
AI 평가자는 모델만이 아니라 모델 + 지시문(프롬프트) + 설정 한 묶음이다.
지시문 한 줄만 바뀌어도 다른 평가자가 된다.
# 아래 예제는 핵심 흐름만 짧게 보여 줍니다.
# 같은 답이라도, 지시문이 바뀌면 점수가 달라짐
평가자_지난달 = (모델, "관대한 지시") # 90점
평가자_이번달 = (모델, "오타 고친 지시") # 92점
# → 앱이 좋아진 게 아니라, 채점자가 바뀐 것일 수 있다!
그래서 규칙: 채점에 쓴 모델과 지시문을 볼 수 없으면, 그 AI 평가자를 믿지 마라.
단순 규칙
AI 평가자에겐 할 일·기준·점수 체계를 또렷이 적고, 점수 체계는 분류나 1~5점을 써라.
한 걸음 더 ▸ (지금 몰라도 됨)
AI 평가자엔 세 가지 단골 편향이 있다.
① 자기 편향 — 자기가 만든 답에 더 후한 점수를 준다. (한 모델은 자기 답에 25% 더 높게 줬다.) ② 위치 편향 — 둘 중 첫 번째 답을 편애한다. (사람은 반대로 마지막 걸 편애 — 최근성 편향.) ③ 장황성 편향 — 품질과 상관없이 긴 답을 좋아한다. (한 답이 두 배 길면 거의 항상 긴 쪽을 고른다.)
완화법: 자기 편향은 다른 모델에게 채점시키고, 위치 편향은 순서 바꿔 여러 번 돌리고, 장황성 편향은 "길이 말고 관련성으로 채점하라"고 지시한다. 모델이 강력해질수록 이 편향들은 줄어드는 경향이 있다.
부록 박스 — 특화 평가자 (참고용, 건너뛰어도 됨)
아무거나 채점하는 범용 평가자 말고, 한 가지만 잘 채점하도록 길들인 특화 평가자도 있다. 작고 특화된 평가자가 오히려 더 믿을 만할 때가 많다.
- 보상 모델 — (질문, 답) 한 쌍을 받아 "이 답 얼마나 좋아"를 점수로 낸다. 구글의 Cappy가 예시(작은 모델인데도 잘함).
- 참조 기반 평가자 — 모범답안과 비교해 점수를 낸다. BLEURT·Prometheus 등.
- 선호도 모델 — (질문, 답1, 답2)를 받아 사람이 어느 쪽을 더 좋아할지 맞힌다. PandaLM·JudgeLM 등.
이름은 외울 필요 없다. "한 가지만 잘하게 만든 채점기들이 있다"만 알면 된다.
5. 정답이 열려 있을 때 — 둘을 나란히 비교하기 (비교 평가)
망가지는 장면
"답이 주관적이라 '몇 점'이라고 못 박기가 너무 어렵다. 노래에 점수 매기는 거랑 똑같다."
이럴 땐 점수를 포기하고 둘을 나란히 놓고 "어느 쪽이 나아?" 만 묻는다.
점수 매기기보다 둘 중 고르기가 훨씬 쉽다.
비유 먼저
댄스 배틀을 떠올려 보자.
댄서마다 "8.5점, 9.1점" 매기긴 어렵다.
하지만 둘을 나란히 춤추게 하고 "누가 더 잘해?" 고르는 건 쉽다.
여러 번 붙여서 더 자주 이긴 쪽이 위 순위. 이게 비교 평가다.
3열표
| 비유 | 코드 | 위험 |
|---|---|---|
| 댄서마다 점수표(개별 평가) | score_A = 8.5; score_B = 9.1 |
주관적인 작업엔 점수 매기기 어려움 |
| 둘 나란히 놓고 고르기(비교 평가) | winner = vote(A, B) # "A" or "B" |
비교할 짝이 모델 수의 제곱으로 폭발 |
| 더 자주 이긴 쪽이 위 순위 | 승률 = A가_이긴_횟수 / 전체_경기 |
"어느 쪽이 나은지"만 알지 "충분히 좋은지"는 모름 |
한 문장 정의
비교 평가는 모델에 점수를 매기는 대신 둘을 직접 비교해 더 나은 쪽을 골라 순위를 매기는 방식이며, 주관적인 작업에 잘 맞는다.
예시 폭격
예시 1 (완성예 — 승률로 순위).
# 아래 예제는 핵심 흐름만 짧게 보여 줍니다.
# 모델 1과 모델 2를 1000번 붙임
모델1_승률 = 0.90 # 모델 1이 90% 이김
# → 모델 1이 모델 2보다 위 순위
LMSYS 챗봇 아레나가 이 방식이다. 사람들이 익명의 두 답 중 나은 쪽에 투표하고, 그걸 모아 순위를 낸다.
예시 2 (부분완성 — 비교 평가가 잘 맞는 작업).
다음 중 비교 평가가 더 쉬운 작업은?
# 아래 예제는 핵심 흐름만 짧게 보여 줍니다.
작업_A = "이 시 두 편 중 어느 게 더 좋아?" # 둘 중 고르기
작업_B = "이 시에 정확히 몇 점?" # 점수 박기
# 더 쉬운 쪽: 작업___
답은 작업_A다.
주관적인 답은 점수를 박기보다 둘 중 고르기가 쉽다.
예시 3 (독립적용 — 비교 평가가 안 맞는 경우).
다음 질문에 비교 평가(선호도 투표)를 쓰면 위험할까?
# `질문`에 중간 결과를 담아 다음 줄에서 재사용합니다.
질문 = "스마트폰 방사선과 뇌종양이 연관 있나요? 예/아니요 골라줘"
# 사용자가 정답을 모르는 사실 질문 → 선호도 투표가 ____
위험하다.
정답이 있는 사실 질문은 "어느 쪽이 마음에 드나"로 고르면 잘못된 답을 고를 수 있다.
비교 평가는 사용자가 이미 아는 일을 더 빨리 시킬 때 잘 맞고, 모르는 일엔 안 맞는다.
미니 시나리오 — "더 낫다"와 "충분히 좋다"는 다르다
"모델 B가 모델 A를 이겼대요. 그럼 B를 쓰면 되겠죠?"
성급하다.
비교 평가는 어느 쪽이 나은지만 알려 준다. 충분히 좋은지는 안 알려 준다.
# 아래 예제는 핵심 흐름만 짧게 보여 줍니다.
# B가 A를 이겼다 → 가능한 경우 3가지
# ① B는 좋고 A는 나쁘다
# ② A도 B도 둘 다 나쁘다 ← 이 경우면 B 써도 망함
# ③ A도 B도 둘 다 좋다
# 어느 경우인지 알려면 다른 채점(절대 점수)이 또 필요하다
단순 규칙
주관적인 답이면 비교 평가, 단 "충분히 좋은지"는 따로 절대 점수로 확인하라.
한 걸음 더 ▸ (지금 몰라도 됨)
비교 평가엔 세 가지 골칫거리가 있다.
① 짝이 폭발한다 — 비교할 모델 짝은 모델 수의 제곱으로 는다. 모델 57개면 짝이 1,596개다. 다 비교하긴 벅차다. ② 품질 관리가 안 된다 — 아무나 아무 프롬프트로 투표한다. 실제로 한 아레나 프롬프트의 0.55%가 그냥 'hello', 'hi'였다. 너무 쉬운 질문은 모델 차이를 못 가린다. ③ 절대 점수를 모른다 — 위 미니 시나리오처럼 "충분히 좋은지"를 못 알려 준다.
그래도 비교 평가는 미래가 밝다. 포화가 없기 때문이다. 점수 시험지는 모델이 만점 받으면 쓸모없어지지만, 비교는 더 센 모델이 나와도 "둘 중 누가 나아?"는 늘 물을 수 있다. 모델이 사람을 넘어서도 사람은 두 답의 차이는 여전히 짚어낼 수 있다. 조작도 어려워, 많은 이가 공개 비교 순위표를 가장 믿는다.
부록 박스 — 순위 알고리즘 (참고용, 건너뛰어도 됨)
누가 누구를 이겼나 데이터를 순위로 바꾸는 계산법은 스포츠·게임에서 빌려 왔다. Elo, Bradley-Terry, TrueSkill 등이다.
LMSYS 아레나는 처음 Elo를 쓰다가, Elo가 채점자·순서에 민감하다는 걸 알고 Bradley-Terry로 갈아탔다.
이름은 분위기만. 결론은 "이긴 기록을 모아 순위로 바꾸는 계산기"다.
정리
이 장은 채점(평가)이 AI 앱에서 제일 어렵다는 데서 출발했다.
- 퍼플렉시티 — 모델이 다음 단어를 얼마나 잘 맞히나(내부 점수). 낮을수록 좋다. 단, 다듬은 모델엔 안 맞는다.
- 정답 있는 작업 — 코드는 돌려보고(기능적 정확성), 번역·요약은 모범답안과 비교한다(어휘적·의미적 유사도).
- 정답 열린 작업 — AI에게 채점 맡기거나(AI 평가자), 둘을 나란히 비교한다(비교 평가). 빠르지만 편향이 있다.
한 걸음 더 ▸ (지금 몰라도 됨)
정확한 채점(코드 실행·유사도)과 주관적 채점(AI 평가자·비교 평가)은 서로를 보완한다. 어느 하나만으로는 부족해서, 실무에선 사람 검토까지 섞어 쓴다.
다음 장 예고 1줄 — 이 장에서 배운 채점법들로 내 앱에 맞는 모델을 고르고 채점 과정을 짜는 법을 본다. (지금 몰라도 됩니다 — 다음 장에서 풀려요.)
연습문제
- 설명.
채점이 제일 어렵다의 핵심을 처음 듣는 사람에게 한 문장으로 설명하라. - 구분. 두 개념(
퍼플렉시티,기능적 정확성)을 실제 예시 하나로 구분하라. - 적용. 내 프로젝트나 학습 노트에서 이 장의 개념을 적용해 작게 개선할 지점을 하나 고르라.
부록 A. 쉬운 용어 사전
| 용어 | 아주 쉬운 뜻 | 이 장에서 나온 위치 |
|---|---|---|
| 퍼플렉시티 | 모델이 다음 단어를 얼마나 헷갈려 하는지 나타내는 숫자. | 부록 B와 본문 예시 |
| 기능적 정확성 | 정답이 있는 문제에서 실제로 맞았는지를 보는 기준. | 부록 B와 본문 예시 |
| AI 평가자 | 다른 AI 모델을 심판처럼 써서 답변 품질을 평가하는 방식. | 부록 B와 본문 예시 |
| 사람 평가자 | 사람이 직접 답변을 읽고 기준에 따라 판단하는 방식. | 부록 B와 본문 예시 |
부록 B. 헷갈리는 개념 비교표
| A | B | 구분 포인트 |
|---|---|---|
| 퍼플렉시티 | 기능적 정확성 | 퍼플렉시티는 모델의 헷갈림, 기능적 정확성은 실제 정답 여부다. |
| AI 평가자 | 사람 평가자 | AI 평가자는 빠르고 싸지만, 사람 평가는 느려도 기준을 더 잘 잡을 수 있다. |
부록 C. 더 읽을 자료
- 이 장의
더 해보기섹션 — 이미 모아 둔 공식 문서나 실습 링크가 있으면 여기서 먼저 확인한다. - 같은 책의
0장 한눈에 보기— 용어가 막히면 0장의 용어집과 개념 척추로 돌아간다. - 원본 딥다이브판 같은 장 — 입문판을 읽고 큰 흐름이 잡힌 뒤 세부 논리를 더 깊게 확인한다.
- 이 장의
flashcards.json— 읽은 직후 질문만 보고 답을 떠올리는 회상 연습에 쓴다.
부록 D. 연습문제 풀이
- 설명 예시.
채점이 제일 어렵다는 거대 모델을 제품에 넣을 때 어떤 선택을 하고 어떻게 확인할지 판단하게 해 주는 장이다. 중요한 것은 용어를 외우는 것이 아니라, 이 개념이 어떤 입력·부품·결정에 영향을 주는지 말로 풀어 보는 것이다. - 구분 예시. 두 개념(
퍼플렉시티,기능적 정확성)의 차이는 이렇게 잡으면 된다. 퍼플렉시티는 모델의 헷갈림, 기능적 정확성은 실제 정답 여부다. 실제 사례를 볼 때는 목적, 입력, 실패했을 때의 증상을 따로 적어 보면 헷갈리지 않는다. - 적용 예시. 가장 작은 개선부터 고른다. 예를 들어 이름을 더 분명히 하거나, 평가 기준을 한 줄 추가하거나, 직접 알 필요 없는 내부 정보를 감추는 식으로 시작한다. 한 번에 크게 갈아엎는 것보다 작은 변경 하나를 확인하며 진행하는 쪽이 입문 단계에 맞다.
클릭하거나 Space를 눌러 뒤집기